\subsection{Le processus de build : \textit{\Gls{maven} + \Gls{tycho}}}
\label{sec:maven_tycho}

Parmi les objectifs initiaux du projet (voir \ref{sec:initial_goals}), on avait
cité l'adoption de \Gls{maven} comme processus de build pour le
plugin développé et tous les projets de l'application.

En ce qui concerne le plugin, la problématique réside dans le fait que la
construction de produits \Gls{eclipse} est fortement liée à l’environnement de développement. 
Il s’agirait donc de mettre en place un 
processus de build dit \textit{\Gls{headless}} de notre plugin. C'est-à-dire un
build fonctionnel hors de l’environnement de développement \Gls{eclipse}.

Plusieurs approches sont aujourd’hui utilisées pour automatiser la construction de
produits \Gls{eclipse}, on peut citer \Gls{buckminster}, BND, et bien d’autres.

\subsubsection{\Gls{maven} VS \Gls{eclipse} \GLS{pde}}

\textsc{Plug-in Development Environment} (\GLS{pde}) désigne une collection
d’outils chargés de la construction, du test, du débogage et du déploiement de 
produits \Gls{eclipse} (plugins, features, update-site, produit \GLS{rcp},
\ldots). Cette collection d'outils utilise des mécanismes dont il faut tenir compte pour
la mise en place de build \textit{\Gls{headless}} par \textsc{\Gls{maven}}.

\input{maven_vs_pde.tex}

Le tableau \ref{tab:maven_vs_pde} présente une partie des aspects à prendre en
compte si l'on souhaite construire des plugins \gls{eclipse} en utilisant maven. Deux principales approches 
ont naturellement émergé à ce sujet: 
\begin{itemize}
  \item La première est une approche \textbf{\textit{POM first}} dans laquelle
  le bundle est plus structuré comme un projet \gls{maven} classique et
  principalement configuré grâce à son \emph{pom.xml}. Migrer un projet existant peut
  engendrer des modifications de la structure du projet. BND permettant de
  construire des bundles \GLS{osgi} en général, est un exemple d'utilisation de
  cette approche.
  \item  La seconde approche dite \textbf{\textit{MANIFEST first}} se base sur
  le manifeste du bundle pour réaliser sa construction. Cette dernière semble une approche séduisante pour migrer les projets existants vers des 
   builds \gls{maven}. \Gls{tycho} est un exemple de mise en oeuvre de cette
   approche, et également la solution retenue pour la construction de notre projet.
\end{itemize}

\subsubsection{Pr\'esentation de \textsc{\Gls{tycho}}}

\Gls{tycho} est un ensemble de plugins \Gls{maven} permettant la
construction de plugins \gls{eclipse} ou de bundle \GLS{osgi} en se basant sur leurs fichiers de
configuration. Il est capable de lire des dépôts \gls{eclipse} au format P2 ou
encore des sites de mises à jour de produits \gls{eclipse} et de les
synchroniser avec le dépôt \gls{maven} local en tant que dépendances. Il étend
\Gls{maven} en définissant des \emph{packaging} supplémentaires permettant de prendre en compte 
la grande variété de produit eclipse. On peut ainsi citer:

\begin{itemize}
  \item \emphbf{eclipse-plugin:} Pour gérer les plugins \gls{eclipse}.
  \item \emphbf{eclipse-feature:} Pour la gestion des features.
  \item \emphbf{eclipse-test-plugin:} Pour la prise en compte des projets de
  tests.
  \item \emphbf{eclipse-udpate-site:} Pour la création d'un site de mise à jour.
  \item \emphbf{eclipse-application:} Pour le \emph{packaging} de product \gls{eclipse}
  (exemple: application \GLS{rcp}).
  \item etc \ldots\\
\end{itemize}

Son intérêt dans la migration d'un projet existant, est le fait qu'il soit
capable de scanner un ensemble de répertoires contenant des projets
\gls{eclipse} et de générer les fichiers pom.xml correspondant à chaque type de projet. 
Les fichiers ainsi générés étant de taille et de contenu relativement minime, 
la majorité de la configuration étant contenue dans un \emph{pom.xml} parent 
à tous ces projets.

\subsubsection{Mise en oeuvre du build \textsc{\Gls{maven}}}

\paragraph{La structure du projet:}

Le projet, défini dans un workspace particulier, se décompose en plusieurs sous
projets, représentant chacun un aspect particulier du système conçu:

\begin{itemize}
  \item \emphbf{com.migration.platform.plugin.main :} Le plugin principal
  contenant toutes les fonctionnalités de base et les points d'extensions.
  \item \emphbf{com.migration.platform.plugin.feature :} Définissant l'ensemble
  des plugins et autres features nécessaires au fonctionnement du plugin
  principal. Il est notamment utilisé pour configurer des lancements ou encore pour construire 
  les sites de mises à jour. On peut également lui attacher une licence 
  de distribution.
  \item \emphbf{com.migration.platform.plugin.update\_site :} Permet de
  construire un \emph{update-site} en se basant sur la \emph{feature}.\\
\end{itemize}

\paragraph{La génération des \emph{pom.xml}:}

Dans un terminal, on se place dans le répertoire représentant le workspace du
projet, et on exécute la commande suivante: 

\begin{figure}[H]
\centering
\lstset{language=sh}
\begin{lstlisting}
mvn org.eclipse.tycho:maven-tycho-plugin:generate-poms
-DgroupId=com.migration.platform -Dversion=1.0.0-SNAPSHOT
\end{lstlisting}
\caption{Processus de build: Commande de génération des fichiers
\emph{pom.xml}}\label{cod:pom_gen_command}
\end{figure}

Les fichiers générés sont les suivants:\\

\begin{itemize}
  \item com.migration.plugin.main/pom.xml
  \item com.migration.plugin.feature/pom.xml
  \item com.migration.platform.plugin.update\_site/pom.xml
  \item pom.xml\\
\end{itemize}

Pour des questions de commodité on déplace le pom.xml parent dans le répertoire 
\emphbf{"com.migration.platform.plugin.build"} que l'on crée à cet effet, ce qui
permet entre autre de pouvoir l'éditer dans \Gls{eclipse}. On met à jour les
\emph{pom.xml} de tous les projets pour prendre en compte le déplacement du
parent.

%\colorbox{imgBackground}{
%\begin{minipage}{\textwidth}
\begin{figure}[H]
\caption{Processus de build: Mise à jour du \emph{pom.xml}
parent}\label{tab:pom_parent_update}
\begin{tabular}{cc}
Avant:\ \ \ 
& 
\begin{minipage}{0.80\linewidth}
\medskip
\lstset{language=XML}
\begin{lstlisting}
 <!-- {...} -->
 <modules>
   <module>com.migration.platform.plugin.feature</module>
   <module>com.migration.platform.plugin.main</module>
   <module>com.migration.platform.plugin.update_site</module>
 </modules>
 <!-- {...} -->
\end{lstlisting}
\medskip
\end{minipage}
\tabularnewline
Après: \ \ \ 
&
\begin{minipage}{0.80\linewidth}
\medskip
\lstset{language=XML}
\begin{lstlisting}
 <!-- {...} -->
 <modules>
   <module>../com.migration.platform.plugin.feature</module>
   <module>../com.migration.platform.plugin.main</module>
   <module>../com.migration.platform.plugin.update_site</module>
 </modules>
 <!-- {...} -->
\end{lstlisting}
\medskip
\end{minipage}
\tabularnewline
\end{tabular}
\end{figure}
%\end{minipage}
%}

\begin{figure}[H]
\caption{Processus de build: Mise à jour des \emph{pom.xml} des
modules}\label{tab:pom_modules_update}
\begin{tabular}{cc}
Avant:\ \ \ 
& 
\begin{minipage}{0.80\linewidth}
\medskip
\lstset{language=XML}
\begin{lstlisting}
 <!-- {...} -->
 <parent>
   <artifactId>com.migration.platform.plugin</artifactId>
   <groupId>com.migration.platform</groupId>
   <version>1.0.0-SNAPSHOT</version>
 </parent>
 <!-- {...} -->
\end{lstlisting}
\medskip
\end{minipage}
\tabularnewline
Après: \ \ \ 
&
\begin{minipage}{0.80\linewidth}
\medskip
\lstset{language=XML}
\begin{lstlisting}
 <!-- {...} -->
 <parent>
   <artifactId>com.migration.platform.plugin</artifactId>
   <groupId>com.migration.platform</groupId>
   <version>1.0.0-SNAPSHOT</version>
   <relativePath>../com.migration.platform.plugin.build/pom.xml</relativePath>
 </parent>
 <!-- {...} -->
\end{lstlisting}
\medskip
\end{minipage}
\tabularnewline
\end{tabular}
\end{figure}
 
\clearpage
 
\paragraph{D\'efinition d'une plateforme cible:}

Une plateforme cible est un mécanisme d'\Gls{eclipse} permettant de spécifier
l’environnement minimum dont a besoin un plugin ou une application \GLS{rcp} 
pour fonctionner. \Gls{tycho} se base sur cette définition de la plateforme
cible pour construire notre projet. Plusieurs solutions sont disponibles pour la
définition de notre plateforme cible.

\begin{itemize}
  \item La première consiste à déclarer des dépôts P2 dans notre pom.xml parent.
  On pourrait par exemple rajouter le dépôt principale d'\gls{helios} de la
  manière suivante: \begin{figure}[H]
  \centering
  \lstset{language=XML}
  \begin{lstlisting}
 <repositories>                                                          
 <!-- {...} -->
   <repository>                                                     
     <id>helios</id>                                          
     <layout>p2</layout>                                      
     <url>http://download.eclipse.org/releases/helios</url>  
   <repository>                                                      
 <!-- {...} -->
 </repositories>     
  \end{lstlisting}
  \caption{Processus de build: exemple de d\'epôt \textsc{\Gls{helios}} dans le
  \textit{pom.xml}}\label{code:p2_helios_target_platform}
\end{figure}

	De la même manière on pourrait rajouter en tant que dépôt les
\textit{update-site} des plugins dont on a besoin, Tycho se charge ensuite de
créer la plateforme cible en fonction des informations fournies dans les
métadonnées de notre plugin. La meilleure manière d'utiliser cette alternative est de se définir une plateforme cible avec juste les 
éléments dont on a besoin, cette dernière peut ensuite être versionnée pour tenir compte 
des modifications majeures que l'on pourrait y apporter; on pourrait ensuite la stocker sur 
un serveur ou un répertoire partager par l'équipe, et la déclarer comme dépôt 
de notre projet.\\
  \item La deuxième possibilité (celle adoptée pour notre projet), est
d'utiliser le fait que \Gls{tycho} soit capable de lire les fichiers de configuration '.target' créer
par \gls{eclipse}. Pour ce faire on rajoute un projet à
notre espace de travail, dans lequel on crée une \textit{Target Definition}. On profite ainsi
de l’éditeur sympathique d'\gls{eclipse} pour la définition de notre
plateforme cible. De plus on a la possibilité de dire à \gls{eclipse} de
n'utiliser que l'ensemble des plugins ou features déclarés dans notre plateforme cible. 
Il faut ensuite rattacher la plateforme cible définie à notre pom.xml parent.
\end{itemize}

\begin{figure}[H]
\centering
\lstset{language=XML}
\begin{lstlisting}
   <!-- {...} -->
    <build>
     <plugins>
      <plugin>
       <groupId>org.codehaus.mojo</groupId>
       <artifactId>build-helper-maven-plugin</artifactId>
       <version>1.5</version>
       <executions>
         <execution>
            <id>attach-artifact</id>
            <phase>package</phase>
            <goals>
              <goal>attach-artifact</goal>
            </goals>
            <configuration>
              <artifacts>
                 <artifact>
                   <file>com.migration.platform.plugin.target</file>
                   <type>target</type>
                   <classifier>com.migration.platform.plugin</classifier>
                 </artifact>
               </artifacts>
             </configuration>
           </execution>
         </executions>
       </plugin>
     </plugins>
   </build>
   <!-- {...} -->
\end{lstlisting}
\caption{Processus de build: Le POM de la plateforme
cible}\label{cod:pom_target_platform}
\end{figure}

On remarque dans l'extrait \ref{cod:pom_target_platform} l'attribut
\emphbf{file} qui contient le nom du fichier décrivant notre plateforme cible,
ce fichier doit se trouver dans le même répertoire que le pom.xml. Le
\emphbf{classifier} correspond quant à lui au nom du même fichier mais sans
l'extension '.target'.

\begin{figure}[H]
\lstset{language=XML}
\begin{lstlisting}
    <!-- {...} -->
    <modules>
     <!-- {...} -->
        <module>../com.migration.platform.plugin.target_platform</module>
    </modules>
     <!-- {...} -->
    <plugin>
     	<groupId>org.sonatype.tycho</groupId>
     	<artifactId>target-platform-configuration</artifactId>
     	<version>0.11.1</version>
     	<configuration>
     		<resolver>p2</resolver>
     		<target>
     			<artifact>
     				<groupId>com.migration.platform.plugin</groupId>
     				<artifactId>target-platform</artifactId>
     				<version>1.0.0-SNAPSHOT</version>
     				<classifier>com.migration.platform.plugin</classifier>
     			</artifact>
     		</target>
     		<environments>
     			<environment>
     				<os>win32</os>
     				<ws>win32</ws>
     				<arch>x86</arch>
     			</environment>
     		</environments>
     	</configuration>
     </plugin>
     <!-- {...} -->
\end{lstlisting}
\caption{Processus de build: Configuration de la plateforme cible dans le POM
parent}\label{cod:pom_parent_target_platform}
\end{figure}

La figure \ref{cod:pom_parent_target_platform} montre comment configurer la plateforme
cible dans le POM parent une fois le fichier "com.migration.platform.plugin.target" créé. On constate 
l'utilisation du plugin \emph{\Gls{tycho}} target-platform-configuration qui
propose la déclaration d'une target que l'on fait correspondre avec notre plateforme cible. Ce plugin joue aussi 
un rôle important pour un développement qui s'orienterait vers du multiplateforme; il permet 
en effet de définir plusieurs environnements d'exécution de notre produit,
chaque environnement étant décrit par le type de système (os), le système graphique utilisé (ws), 
et une architecture cible (arch).

\subsection{Int\'egration continue}

\subsubsection{Installation et configuration}

L' installation et les tests d' intégration continue ont été réalisés dans les conditions suivantes:

\begin{itemize}
  \item Système d'exploitation Windows XP
  \item \Gls{maven} 3.0.3
  \item JBoss Application Server 6.0.0
  \item \Gls{hudson} 2
  \item \GLS{jdk} 1.6 \\
\end{itemize}

Une fois JBoss installé et \Gls{hudson} déployé. On accède à l'interface
utilisateur de \Gls{hudson} dans un navigateur grâce au lien suivant
"http://$<$adresse de la machine$>$:8080/hudson".

Dans l'interface de configuration de \Gls{hudson}:
\begin{itemize}
  \item On vérifie la présence des plugins \Gls{maven} et Svn.
  \item On configure les chemins d'accès vers une \GLS{jdk} et vers notre
  installation de \gls{maven}. On a aussi la possibilité de configurer
  \Gls{hudson} pour qu'il les installe automatiquement.
\end{itemize}

\subsubsection{Création d'une tâche}

\begin{itemize}
  \item On crée une nouvelle tâche en cliquant sur l'onglet nouvelle tâche de la
  page principale d'\Gls{hudson}.
  \item Il s'agit ensuite de renseigner le nom de la tâche dans notre cas "Migration Platform Plugin" et 
  de sélectionner comme type de tâche un projet \Gls{maven} 2/3.
  \item Une fois la création de la tâche terminée, cette dernière apparaît dans la liste des tâches sous 
  forme de lien pointant vers son tableau de bord.
  \item Le tableau de bord de la tâche permet de la piloter et de la configurer. On doit en effet choisir 
  \emph{\Gls{svn}} comme \emph{\GLS{scm}} et renseigner l'adresse du
  serveur.
  \item On enregistre ensuite les données d'accès au serveur
  \textsc{\Gls{svn}} ce qui évite de les renseigner avant le lancement de
  chaque build.
  \item On doit ensuite renseigner \Gls{hudson} sur la localisation du fichier
  \emph{pom.xml} principale vu que ce dernier ne se trouve pas à la racine du
  projet. Dans notre cas: \\
  \emphbf{com.migration.platform.plugin.build/pom.xml}.
  \item Le lancement d'un build peut désormais s'effectuer à partir du tableau
  de bord de la tâche. A noter que le premier build peut durer un certain temps
  du fait de la résolution des dépendances des plugins \emphbf{eclipse} du projet.
\end{itemize}

